REMARKS 

Careful review and examination of the subject application 
are noted and appreciated. 



SUPPORT FOR THE CLAIM AMENDMENTS 

Support for the claim amendments may be found in the 
specification, for example, on page 10 lines 1-6 and FIG. 2 blocks 
154 and 156, as originally filed. Furthermore, claims 11 and 17 
have been brought into closer alignment with claim 1. Thus, no new 
matter has been added and no new issues are believed to be raised 
for the independent claims. Since the amendments should only 
require a cursory review, entry of the amendments for the purpose 
of an appeal is respectfully requested under MPEP §714.13 II. If 
the amendments are not entered, Applicants respectfully request a 
concise explanation per MPEP §714.13 III. 

CLAIM REJECTIONS UNDER 35 U.S.C. SI 02 

The rejection of claims 1, 2, 4, 9, 11, 12, 14, 16, 17 
and 20 under 35 U.S.C. §102 (e) as being anticipated by Lyon et al. 
x 917 (hereafter Lyon) has been obviated in part by appropriate 
amendment, is respectfully traversed in part, and should be 
withdrawn . 

Lyon concerns a method and apparatus for RED (Random 
Early Detection) and enhancements (Title) . 
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Claim 1 further provides a test circuit configured to 
present an identification signal to a sender of an additional data 
packet, the identification signal indicating that the additional 
data packet was discarded. In contrast, Lyon does not appear to 
expressly or inherently disclose that (i) a Drop/Tag block 40 plus 
a RED engine 38 (asserted similar to the claimed test circuit) 
generates an identification signal back to a source 32 (asserted 
similar to the claimed sender) or (ii) sends any signal indicating 
that a packet was dropped. Therefore, Lyon does not disclose or 
suggest a test circuit configured to present an identification 
signal to a sender of an additional data packet, the identification 
signal indicating that the additional data packet was discarded as 
presently claimed. 

Furthermore, the "implicit signal" mentioned on page 3 of 
the Office Action appears to be a function of the TCP protocol 
rather than the RED engine 38 of Lyon. According to the 
Encyclopedia of Networking, Electronic Edition (see Appendix A) 
page 951, "The receive can acknowledge receipt of datagrams to 
provide assurance of delivery to the sender." Therefore, if the 
RED engine 38 of Lyon discards a packet, the sender on its own can 
determine that the packet has been lost somewhere due to the lack 
of an acknowledge packet from the intended receiver per the TCP 
protocol. Lyon appears to disclose a different structure than 
claim 1 for notifying a source of a lost packet. Therefore, Lyon 
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does not appear to disclose or suggest a test circuit configured to 
present an identification signal to a sender of an additional data 
packet as presently claimed. Claims 11 and 17 provide language 
similar to claim 1. As such, the claimed invention is fully 
patentable over the cited reference and the rejection should be 
withdrawn. 

Claim 2 provides that the test circuit is configured to 
always discard the additional data packet without storing the 
additional data packet in the buffer in response to a number being 
at least as great as a second threshold. In contrast, Lyon states 
in column 2 lines 1-2, u If the average queue size exceeds the 
maximum threshold, all arriving packets are marked." Lyon further 
states in column 1 lines 61-66 that marking can be accomplished 
using an Explicit Forward Congestion Indication field in the ATM 
cells. Lyon appears to contemplate that additional packets can be 
kept even if the average queue depth is above the maximum threshold 
(asserted similar to the claimed second threshold) . Therefore, 
Lyon does not appear to disclose or suggest a test circuit 
configured to always discard an additional data packet without 
storing the additional data packet in a buffer in response to a 
number being at least as great as a second threshold as presently 
claimed. Claim 12 provides language similar to claim 2. As such, 
claims 2 and 12 are fully patentable over the cited reference and 
the rejection should be withdrawn. 
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Claims 9, 16 and 20 depend from either independent claims 
1 or 11, which are now believed to be allowable. Since the 
dependent claims contain all of the limitations of the independent 
claims, claims 9, 16 and 20 are fully patentable over the cited 
reference and the rejection should be withdrawn. 

CLAIM REJECTIONS UNDER 35 U.S.C. §103 

The rejection of claims 6-8 under 35 U.S.C. §103 (a) as 
being unpatentable over Lyon in view of Skirmont x 848 is 
respectfully traversed and should be withdrawn. 

The rejection of claims 5, 10, 15, 18 and 19 under 3 5 
U.S.C. §103 (a) as being unpatentable over Lyon in view of Ikeda 
v 853 is respectfully traversed and should be withdrawn. 

The rejection of claims 21 and 22 under 35 U.S.C. §103 (a) 
as being unpatentable over Lyon in view of Bechtolsheim x 963 is 
respectfully traversed and should be withdrawn. 

Lyon concerns a method and apparatus for RED (Random 
Early Detection) and enhancements (Title) . Skirmont concerns 
system performance in a data network through queue management based 
on ingress rate monitoring (Title) . Ikeda concerns a congestion 
control method in an ATM network based on threshold values of node 
queue length (Title) . Bechtolsheim concerns a per-flow dynamic 
buffer management (Title) . 
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Regarding claims 6-8, the Office Action has not provided 
clear and particular evidence of motivation to combine the 
references. In particular, the alleged motivation on page 4 of the 
Office Action "to improve the system performance by adjusting the 
packets dropping to meet different system requirements" does not 
appear to be credited to the references or knowledge generally 
available to one of ordinary skill in the art as required by MPEP 
§2142. Furthermore, the need for "adjusting the packets dropping 
to meet different system requirements" does not appear to be 
expressed by any of the references as a problem to be solved per In 
re Huston. Therefore, prima facie obviousness has not been 
established for lack of clear and particular evidence of motivation 
to combine the references. The Examiner is respectfully requested 
to either (i) clearly identify the source of the alleged motivation 
or (ii) withdraw the rejection for claims 6-8. 

Regarding claims 5, 10, 15, 18 and 19, the Office Action 
has not provided clear and particular evidence of motivation to 
combine the references. In particular, the alleged motivations on 
page 5 of the Office Action (i) "to reduce unnecessary packet 
transmission from the source when the buffer is full" and (ii) "to 
utilize full packet transmission rate from the source in the 
absence of congestion" do not appear to be credited to the 
references or knowledge generally available to one of ordinary 
skill in the art as required by MPEP §2142. Furthermore, the need 



12 



to "reduce unnecessary packet transmission" and "utilize full 
packet transmission rate from the source" do not appear to be 
expressed by any of the references as problems to be solved per In 
re Huston. Therefore, prima facie obviousness has not been 
established for lack of clear and particular evidence of motivation 
to combine the references. The Examiner is respectfully requested 
to either (i) clearly identify the source of the alleged motivation 
or (ii) withdraw the rejection of claims 5, 10, 15, 18 and 19. 

Regarding claims 21 and 22, the Office Action has not 
provided clear and particular evidence of motivation to combine the 
references. In particular, the alleged motivations on page 4 of 
the Office Action "to improve system performance when interfacing 
to several output ports" does not appear to be credited to the 
references or knowledge generally available to one of ordinary 
skill in the art as required by MPEP §2142. Furthermore, the need 
for "interfacing to several output ports" does not appear to be 
expressed by any of the references as problems to be solved per In 
re Huston. Therefore, prima facie obviousness has not been 
established for lack of clear and particular evidence of motivation 
to combine the references. The Examiner is respectfully requested 
to either (i) clearly identify the source of the alleged motivation 
or (ii) withdraw the rejection of claims 21 and 22. 

Furthermore, one of ordinary skill in the art would 
appear to be unmotivated to make the proposed combination. In 
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particular, column 2, lines 26-33 of Bechtolsheim asserts that a 
port scheduler 50 provides a "statistically fair scheduling 
process" such that "one packet is read out of each queue, one queue 
at a time." In contrast, Lyon only appears to disclose a single 
queue 36. One of ordinary skill in the art would appear to be 
unmotivated to add the cost and complexity of the port scheduler 50 
of Bechtolsheim to the switch 34 of Lyon where there is only a 
single queue 36 from which to read out the packets. Therefore, 
prima facie obviousness has not been established due a motivation 
NOT to combine the references. 

IMPROPERLY EXPRESSED REJECTIONS 

Applicant's representative respectfully requests that a 

new Office Action, or Notice of Allowance, be issued due to a lack 

of proper development for the rejections in the current Office 

Action. In particular, Applicant's representative traversed the 

asserted motivation in the last Office Action to combine the 

primary reference with Skirmont. MPEP §707.07 (f) states: 

Where the applicant traverses any rejection, the examiner 
should, if he or she repeats the rejection, take note of the 
applicant's argument and answer the substance of it. 
(Emphasis added) 

However, the current Office Action repeats the asserted motivation 
word-for-word, but does not answer the substance of the traverse. 
Applicant should not have to endure the trouble and expense of 
filing an RCE or an appeal to learn why the Examiner believes 
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Applicant's traverse to be incorrect. As such, the current Office 
Action is incomplete and a new Office Action, or Notice of 
Allowance, should be issued. 

Accordingly, the present application is in condition for 
allowance. Early and favorable action by the Examiner is 
respectfully solicited. 

The Examiner is respectfully invited to call the 
Applicant's representative at 586-498-0670 should it be deemed 
beneficial to further advance prosecution of the application. 

If any additional fees are due, please charge Deposit 
Account No. 12-2252. 

jtfully submitted, 
!)PHER P. MAIORANA, P.C. 




rana 
No. 42,829 



Dated: May 6, 2 005 



c/o Peter Scott 

LSI Logic Corporation 

1621 Barber Lane, M/S D-106 Legal 

Milpitas, CA 95035 

Docket No.: 1496.00062 



15 



J a/ J, 



Encyclopedia of Networking, 
Electronic Edition 



Tom Sheldon 



Osborne McGraw-Hill 

Berkeley New York St. Louis San Francisco 
Auckland Bogota Hamburg London Madrid 
Mexico City Milan Montreal New Delhi Panama City 
Paris Sao Paulo Singapore Sydney 
Tokyo Toronto 



BEST AVAILABLE COPY 



Osborne/McGraw-Hill 

2600 Tenth Street 
Berkeley, California 94710 
U.S.A. 

For information on translations or book distributors outside the U.S.A., or to arranee 
bulk purchase discounts for sales promotions, premiums, or fund-raisers, please 
contact Osborne/McGraw-Hill at the above address. 

Encyclopedia of Networking, Electronic Edition 

vS^f ^ ^ McGraW " Hi11 Companies. All rights reserved. Printed in the 
United States of America. Except as permitted under the Copyright Act of 1976, no 
part of this publication may be reproduced or distributed in any form or by an V 
means, or stored in a database or retrieval system, without the prior written 
permission of the publisher, with the exception that the program listings may be 

fo^SfcSS' eX6CUted " 3 C ° mpUter SyStem ' but the y ma y not ^ reproduced 
1234567890 DOC DOC 901987654321098 



ISBN 0-07-882333-1 PPBK 

Publisher 

Brandon A. Nordin 

Editor-in-Chief 

Scott Rogers 

Acquisitions Editor 

Wendy Rinaldi 

Project Editor 

Emily Rader 

Editorial Assistant 

Ann Sellers 

Technical Editor 

Tere Parnell 

Copy Editor 

Dennis Weaver 



ISBN 0-07-882350-1 HRDBK 

Proofreader 

Karen Mead 

Indexer 

Dan Logan 

Computer Designer 

Jani Beckwith 

Illustrators 

Sue Albert 
Leslee Bassin 
Arlette Crosland 
Lance Ravella 

Cover Design 

Regan Honda 



PFST AVAILABLE COPY 



TCP (Transmission Control Protocol) ; 9S1 



■ The receiver can acknowledge receipt of datagrams to provide assurance of 
delivery to the sender . This acknowledgment scheme is used in a number of 
ways, as discussed in a moment. 

■ Flow control provides a way for two systems to actively cooperate in the 
transmission of data to prevent overflows and lost datagrams caused by fast 
senders. This feature lets transmitting systems quickly adapt to the traffic loads 
on the network and /or the available buffer size on the receiver. 

■ Sequencing is a technique for numbering datagrams so the receiver can put 
them back into the correct order and determine if datagrams are missing. 

■ A checksumming feature is used to ensure the integrity of packets. 

TCP Segments 

A TCP segment is the official name for what is often loosely referred to as a packet 
(where a packet is some package of information). A segment is the actual entity that 
TCP uses to exchange data with its peers. The segment is what gets encapsulated into 
an IP datagram and transmitted across the network. Segments have a 20-byte header 
and a variable-length Data field. The fields of the TCP segment are described below 
and pictured in Figure T-4. Keep in mind that either station may send a segment that 
contains just header information and no data to provide the other system with 
connection information, such as an acknowledgment that a segment was received. 

■ Source and destination port Contains the port number of the sockets at the 
source and destination sides of the connection. 

■ Sequence number This field contains information for the receiver, which is a 
sequential number that identifies the data in the segment and where it belongs 
in the stream of data that has already been sent. The receiver can use the 
sequence number to reorder packets that have arrived out of order. It can also 
indicate that a segment is missing. 

■ Acknowledgment number This field is used by the receiver to indicate to the 
sender in a return message that it has received a previously sent packet. The 
number in this field is actually the sequence number for the next segment that 
the receiver expects. That number is calculated by incrementing the value in 
the Sequence Number field. 

■ TCP header length Specifies the length of the header. 

■ Codes This field contains the following bit codes, which serve as flags to 
indicate specific conditions: 

URG (urgent) This bit is set to 1 if there is information in the Urgent Pointer 
field of the header. 

ACK (acknowledgment) If ACK is set to 1, it indicates that the segment is 
part of an ongoing conversation and the number in the Acknowledgment 
Number field is valid. If this flag is set to 0 and SYN is set to 1, the segment is 
a request to establish a connection. 
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